User talk:DarthKitty/Lua style guide
Parallel assignment The problem with parallel assignment is that you have to mentally find the correct name-value pairs, which makes it more time-consuming to read than separate assignment. +--------------------------------+ | | | +--------------------+ | | | | | | | +-------+ | | | | | | | | local one, two, three = 'foo', 'bar', 'baz' Even if every value is the same, other devs won't automatically know that; they'll either match pairs like I described above, or compare the values to determine if they're equal. Either way involves parsing. +--------+ | | +--------+ | | | | local text1, text2, text3 = 'equal', 'equal', 'equal' In fact, the only cases where parallel assignment does NOT create more work are... When all values are nil Parallel assignment is okay here because there are no values to match or compare. |-|Parallel= local empty1, empty2 |-|Separate= local empty1 local empty2 When all values are returned from a single function Parallel assignment is okay here because the alternative is ridiculous. |-|Parallel= local function multiReturn() return 1, 2, 3 end local value1, value2, value3 = multiReturn() |-|Separate= local function multiReturn() return 1, 2, 3 end local value1 = multiReturn() local value2 = select(2, multiReturn()) local value3 = select(3, multiReturn()) When swapping variables Parallel assignment is okay here because the alternative is confusing and requires an extra variable. |-|Parallel= local foo = 'first value' local bar = 'second value' foo, bar = bar, foo |-|Separate= local foo = 'first value' local bar = 'second value' local temp = foo foo = bar bar = temp temp = nil -- Optional: delete temp Conclusion I'm explaining all of this because oldid=28921}} Dessamator's recent edit made me wonder if the corresponding section of the style guide is clear enough. Suggestions are welcome! DarthKitty (talk) 18:25, July 21, 2015 (UTC) Discussion While I generally agree with the idea. I think that if all the variables are initialized to the same value, there is no point in many in individual lines. Although if many variables are initialized it may be worth using a changing it to a table. In some cases it may be useful to show what type of value the variable uses because scripting languages don't have a specific type for variables and that may lead to guessing. Yeah, but how often does anyone need more than two variables initialized to the same value? Sounds like an edge case to me. DarthKitty (talk) 20:10, July 21, 2015 (UTC) : I can't speak for other coders, but I often initialize quite a lot of tables, numbers or strings and they are often empty or 0. Any script of moderate size is going to use a lot of variables or tables that they will most certainly initially prior to using them. Some of the scripts (e.g. Module:Date) I've copied here from other authors also seem to do the same thing. The general rule is also that you shouldn't initialize variables inside loops, so I often initialize a lot of them outside, unless the benefits are little or I'm quickly debugging a script. Dessamator (talk) 15:22, July 22, 2015 (UTC) There's nothing wrong with creating a bunch of variables per se, but if you find yourself writing something like this... |-|Separate= local foo = "" local bar = "" local baz = "" local qux = "" |-|Parallel= local foo, bar, baz, qux = "", "", "", "" ...you probably need to refactor your code. Case in point, Module:Links. DarthKitty (talk) 23:21, July 22, 2015 (UTC) That's a good point, well in the end it comes down to coding style, and I'm guessing the current guide probably dissuades coders from writing a lot of variables they forget about.Dessamator (talk) 10:19, July 23, 2015 (UTC)